\chapter{Xen Virtualization}
\label{cha:xen}

\section{Introduction}
\label{sec:XenIntro}

\emph{Write the stuff here} 

\cite{garfinkel03terra}
Commodity computing systems have reached an impasse. There is an increasing need to deploy systems with diverse security requirements in enterprise, government, and consumer applications.
However, current hardware and operating systems impose fundamental limitations on the security these platforms can provide.

First, commodity operating systems are complex programs that
often contain millions of lines of code, thus they inherently offer
low assurance. Building simple, high-assurance applications on
top of these operating systems is impossible because applications
ultimately depend on the operating system as part of their trusted
computing base.

Next, commodity operating systems poorly isolate applications
from one another. As a result, the compromise of almost any application
on a platform often compromises the entire platform. Thus,
applications with diverse security requirements cannot be run concurrently,
because the platform’s security level is reduced to that of
its most vulnerable application.

Further, current platforms provide only weak mechanisms for
applications to authenticate themselves to their peers. There is no
complete and ubiquitous mechanism for distributed applications to
verify the identities of programs they interact with. This makes
building robust and secure distributed applications extremely difficult,
as remote peers must be assumed to be malicious. It also
significantly limits the threat models that can be addressed. For
example, an online game server cannot tell whether it is interacting
with a game client that will play fairly or one which has been
subjected to tampering that will allow users to cheat.
Finally, current platforms provide no way to establish a trusted
path between users and applications. For example, an application
for trading on financial markets has no way of establishing if its inputs
are coming from a human user or a malicious program. Conversely,
human users have no way of establishing whether they are
interacting with a trusted financial application or with a malicious
program impersonating that application.


To address these problems, some systems resort to specialized
closed platforms, e.g. cellular phones, game consoles, and ATMs.
Closed platforms give developers complete control over the structure
and complexity of the software stack, thus they can tailor it to
their security requirements. These platforms can provide hardware
tamper resistance to ensure that the platform’s software stack is not
easily modified to make it misbehave. Embedded cryptographic
keys permit these systems to identify their own software to remote
systems, allowing them to make assumptions about the software’s
behavior. These capabilities allow closed platforms to offer higher
assurance and address a wider range of threat models than current
general-purpose platforms.
The security benefits of starting from scratch on a “closed box”
special-purpose platform can be significant. However, for most applications
these benefits do not outweigh the advantages of generalpurpose
open platforms that run many applications including a huge
body of existing code and that take advantage of commodity hardware
(CPU, storage, peripherals, etc.) that offers rich functionality
and significant economies of scale. In this work, we describe a software
architecture that attempts to resolve the conflict between these
two approaches by supporting the capabilities of closed platforms
on general-purpose computing hardware through a combination of
hardware and operating system mechanisms.

Our architecture, called Terra, provides a simple and flexible programming
model that allows application designers to build secure
applications in the same way they would on a dedicated closed platform.
At the same time, Terra supports today’s operating systems
and applications. Terra realizes this union with a trusted virtual machine
monitor (TVMM), that is, a high-assurance virtual machine
monitor that partitions a single tamper-resistant, general-purpose
platform into multiple isolated virtual machines. Using a TVMM,
existing applications and operating systems can each run in a standard
virtual machine (“open-box VM”) that provides the semantics
of today’s open platforms. Applications can also run in their
own closed-box virtual machines (“closed-box VMs”) that provide
the functionality of running on a dedicated closed platform. The
TVMM protects the privacy and integrity of a closed-box VM’s
contents. Applications running inside a closed-box VM can tailor
their software stacks to their security requirements. Finally, the
TVMM allows applications to cryptographically authenticate the
running software stack to remote parties in a process called attestation.







\cite{garfinkel03terra}


%\section{Approach to the Literature Survey}
%
%Although Process migration was a hot topic in systems research for some years back, Process Migration on \emph{Paravirtualized environments} like XEN Hypervisor is a good area to do a research. Having the background knowledge on Virtualization and Paravirtualization, as it was my Third Year Group Project, and as I very much interested and willing to do a research in my 4th year I choose this topic for my Literature Survey.
%
%Though the topic limits to the XEN, research papers and articles related to process migration in generic should be studied. Problems and barriers of implementing it in real world, in the context of Process migration should be studied. Existing implementations such as Zap, VMMigration,$\mu$Denali~\cite{Whitaker_CSIVH}, Sprite, and MOSIX should be firmly studied. Finally I plan to research on \emph{how process migration on XEN has done and how it can be improved}.

\section{Organization of the report}
